home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1989 / Jun 89 / V0086-Re Extending Object-Jun89 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.5 KB  |  49 lines  |  [TEXT/GEOL]
  1. Item    7541918                         28-June-89        06:58
  2.  
  3. From:   PASCOE1                         Pascoe, Geoff
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Re to Extending Object Pascal
  8.  
  9. Andy,
  10.  
  11. It's not clear to me how an addition to TObject is going to help you free an
  12. instance variable and set it to NIL.
  13.  
  14. On the subject of an improved Object Pascal- I agree it can use some
  15. enhancements.  But, I would argue that all those GROSS C++ "features" are what
  16. we need.  For example, constructors and destructors kind of seem nice at first
  17. glance, but when you look under the covers its not so great.  Stack allocating
  18. objects with constructors and destructors very tightly couples an objects
  19. internal implementation to the modules that use that object.  If you change the
  20. data in the object you have to recompile all the modules that use that object
  21. because the amount of data allocated on the stack is going to change
  22. (admittedly currently this is somewhat of a problem with the current Object
  23. Pascal since all instance variables are visible and we use make that works on a
  24. file level granularity).  Also, the inline code generated with constructors and
  25. destructors can become quite large when, for example, the number of directions
  26. the flow of control can take is large (e.g., in a CASE statement).
  27. Constructors and destructors can considerably complicate automatic storage
  28. management (usually called, imprecisely, Garbage Collection), assuming you feel
  29. that this would be useful.
  30.     I feel that the types of improvements we make should be more toward the
  31. line of flexibility, more decoupling of the interface from implementation.
  32. Incremental garbage collection (e.g., Generational Scavenging) can be very
  33. efficient, some even approaching the efficiency of stack allocation.  Probably
  34. some of the biggest improvements we could make is to decouple the languages
  35. implementation more from its specification.  For example, why should I have to
  36. worry about passing instance variables as VAR parameters, or if the instance
  37. variable is larger than 4 bytes, I'll typically have to assign it to a
  38. temporary.  Things like this seem to me to be implementation unduly influencing
  39. the language specification.
  40.     Speaking of specifications, it would be really nice to have something a
  41. little more in depth than the current manual.  I am continually surprised at
  42. the types of things the compiler does, especially when casting pointers (Did
  43. you know that this is potentially an active operation?)
  44.     I guess I'll get off the soap box.
  45.  
  46. Geoff
  47.  
  48.  
  49.